Why is this commented out?

If it doesn't apply, then just remove the code?

Its to document that the omission is intentional and not a miss, this is the actual value that we would be getting in 2 cases:

1. If we call before we have a valid row
2. If the value for the row-column is NULL

Happy to remove it or add a comment clarifying.

It looks like a mistake. An explicit comment is better.

Added comment. Please take another look.

👍

Why are these all public?

Just had my Java brain on. Making them private.

Well this is unfortunate - this means we are saying *any instead of any. I know that's the existing behavior, but does that even work?

*any is the expected type, see the Rows.Scan() docs:

// If an argument has type *interface{}, Scan copies the value
// provided by the underlying driver without conversion. When scanning
// from a source value of type []byte to *interface{}, a copy of the
// slice is made and the caller owns the result.

Relevant code:

case nil:
    switch d := dest.(type) {
    case *any:
	if d == nil {
		return errNilPtr
	}
	*d = nil
	return nil

In our case, this works:

	for rr.Next() {
		cc, err := rr.ColumnTypes()
		if err != nil {
			log.Fatal(err)
		}

		pointers := make([]any, 0)
		for _, ct := range cc {
			fmt.Printf("%s ", ct.ScanType())
			pointers = append(pointers, reflect.New(ct.ScanType()).Interface())
		}
		fmt.Println()

		if err := rr.Scan(pointers...); err != nil {
			log.Fatal(err)
		}

		fmt.Println(pointers...)
		for _, p := range pointers {
			if pn, ok := p.(**any); ok {
				fmt.Printf("%t ", *pn == nil)
			}
		}

	}

sql.NullInt64 sql.NullString sql.NullFloat64
&{1 true} &{hello true} &{3.1415 true}
sql.NullInt64 *interface {} *interface {}
&{2 true} 0xc000064090 0xc000064098
true true

That's unrelated. Rows.Scan is talking about its arguments, which by necessity all have to be pointers as they are essentially output parameter. Meanwhile, ColumnTypeScanType is talking about the type to scan into (so not a pointer).

For example, ColumnTypeScanType mentions returning reflect.TypeOf(int64(0)) while Rows.Scan mentions *int64.

You'll also notice that all the other types being returned (e.g., TYPE_NULLSTRING) here are not pointers.

In other words, you are supposed to create a variable of the type from ColumnTypeScanType, and then pass a pointer to it to Rows.Scan.

You are right. I will return interface{} now, following Go 1.21 , although this has been changed for Go 1.24 for compatibility.

Still, this might break code depending on the previous behavior.

If the SQL statement does not currently point to a valid row, or if the column index is out of range, the result is undefined.

We cannot call this if we haven't called Next yet, or if we have iterated past the last row, even if it happens to work today.

I am not sure if you mean

1. SQLiteRows.ColumnTypeScanType() should make sure that we have a valid row so it does not run into undefined behavior, in which case it should signal an error condition, or
2. The driver should not call C.sqlite3_column_type() except inside Next(), which is the only point at which we can assure that we have a valid row.

If it is the first, the method signature does not allow a clear way of signaling errors (except for the empty interface, which signals not-supported) and I can't find a way to know if we have a valid row. The design of the packages (sql and go-sqlite3) seems to imply this should not be a concern beyond Next() and Scan(). Also the docs do not prescribe a context in which it is ok to call this method, but they do for other methods like Close() and Scan() implying it should always be ok to call SQLiteRows.ColumnTypeScanType(). The risk here is that the undefined behavior might mask as a type that is actually invalid for scanning. But, the implication is that the calling code would then try to Scan(), at which point it would get an error, so I see the risk as mitigated.

If it is the second, it is troublesome because that means there is no way of getting the rows without risking a type conversion unless the types are known by the calling code.

This is a method on SQLiteRows, which certainly has the ability to know whether Next has been called yet, and whether the last call returned io.EOF. See sqlite3_stmt_busy.

Also, "undefined behavior" means that anything could happen, including an application crash, now or in the future.